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MULTI -BROADCAST BANDWIDTH CONTROL SYSTEM 

BACKGROUND OP THE INVENTION 

1. Related Applications 

This application is designed to make use of in- 
formation supplied by ground stations as taught in our co- 
pending U.S. Application Serial No. 08/854,104 filed 11 May 
5 2001 for a Dual Mode of Operation Multiple Access System 
for Data Link Communication which is incorporated by refer- 
ence herein. 

2. Field of the Invention 

The present - invention relates to communication 
fiO networks of the type employed between airborne platforms 
v y and ground stations. 'More-- particularly, the present inven- 
?U tion relates to a method and system for controlling the 
% bandwidth of data transmitted by airborne transmitters to 
*£ multiple ground station receivers. 
*15 3. Description of the Prior Art 

^ Heretofore, point-to-point networks have been em- 

it! ployed as intranets in businesses and as internets in the 
p worldwide web. Point-to-point communications relate to a 

message or data sent to a particular receiver or user from 
20 a single source. When there are a number of receivers, the 
same message must be sent to each of the receivers which 
increases the bandwidth proportional to the number of re- 
ceivers. U.S. Patents 6,038,216 and 6,046,980, and refer- 
ences cited therein, have suggested a method and system for 
25 managing bandwidth in point-to-point networks by assigning 
priorities to the type of data and to the individual re- 
ceivers or users. There are no known systems or apparatus 
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for prioritizing messages and data in multi-broadcast or 
point-to-multipoint network systems. 

It would be highly desirable to provide a method 
and a system for managing bandwidth in a point-to- 
multipoint central node airborne broadcasting system. 

SUMMARY OF THE INVENTION 

It is a primary object of the present invention 
to provide a system and method for managing bandwidth in 
User Datagram Protocol (UDP) systems. 

It is a primary object of the present invention 
to provide a system and method for simultaneously managing 
bandwidth in both point-to-point and point-to-multipoint 
broadcast networking systems. 

It is a principal object of the present invention 
to provide a system and method for simultaneously managing 
bandwidth in Transmission Control Protocol (TCP) and UDP 
systems. 

It is a primary object of the present invention 
to provide a system and method for converting TCP data to 
UDP data. 

It is a primary object of the present invention 
to provide a dedicated controller or personal computer (PC) 
for reading fields of- a -TCP header and determining whether 
or not it will be converted into a UDP format data and 
header . 

It is a principal object of the present invention 
to provide a dedicated controller or PC for assimilating 
data from a plurality of TCP headers and converting the TCP 
data into UDP headers and data for multipoint broadcasting 
of data. 
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It is a primary object of the present invention 
to provide a method and system for broadcasting TCP headers 
and data and UDP headers and data randomly intersperced. 

According to these and other objects of the pres- 
ent invention there is provided a communications network 
between an airborne platform and a plurality of ground sta- 
tions (or a central node and a plurality of internet sta- 
tions or nodes) . A bandwidth flow control system is inter- 
posed between the stations and the central hub or platform 
which manages flow bandwidth of data in both TCP and UDP 
format simultaneously. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a table showing the seven protocol 
layers or levels of information used in Open Systems Inter- 
face (OSI) standard protocols; 

Figure 2 is a schematic representation or ar- 
rangement of data in an Internet Protocol Header (IP 
Header) layer shown in Figure 1; 

Figure 3 is a schematic representation of a UDP 
Header which resides in the data field of the IP Header; 

Figure 4 is a schematic representation of a TCP 
Header which resides in the data field of the IP Header; 
and 

Figure 5 is a block diagram of the preferred em- 
bodiment of the present invention showing a computer in a 
central hub or airborne station connected to both a conven- 
tional internet network and to an airborne communications 
network. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Before referring to a detailed description, the 
applicants will use in this application the terms central 
node or central hub to mean any transmitting station that 
transmits to and receives from a plurality of stations 
various types of data. Thus, typical systems that would be 
employed in the present invention would be a system on the 
internet, a segment of the internet and/or a military air- 
borne platform that disseminates surveillance data over 
wireless communication means to a plurality of ground sta- 
tions . 

Refer now to Figure 1 showing a table 10 having 
seven layers of protocol information as used in an OSI 
standard protocol system. The purpose of the OSI layers 
and the different layers within the OSI protocol is to pro- 
vide a set of services at each of the layers which allows 
the layers to communicate with each other and allows com- 
puters or other devices to communicate with each other. 
The known layers are numbered LI to LI. 

Refer now to Figure 2 showing a schematic repre- 
sentation of the arrangement of data in the L3 network 
layer (IP Header) layer shown in Figure 1. The IP Header 
format 12 is shown comprising rows of 32 bits numbered 0 to 
31. The first five of the rows comprises 20 bytes and form 
the IP Header as part of the total length of the IP Header 
format. The field 13 is used to identify the version of IP 
Header being used. The field 14 is used to identify the 
number of 32 bit rows in the IP Header format. The field 
15 is used to identify the type of service which was for- 
merly a quality of service (QoS) and is now used for vari- 
ous uses. The field 16 is employed to denote the total 
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length of the complete IP Header format as shown in the 
right margin. Since the data field 18 may comprise a vari- 
able number of rows R7 to RX, the total length of the IP 
Header format is needed. The only other field of impor- 
5 tance to this invention is the field 11 which is used to 
designate the destination IP address. The remaining fields 
which have not been specifically discussed are standards 
fields and are found in textbooks and do not require addi- 
tional explanation herein. 
10 Refer now to Figure 3 showing a schematic repre- 

sentation of a UPD Header format which comprises two rows 
of 32 bits each comprising eight bytes and a data field 
which may comprise a variable length of data as will now be 
v3 explained. The UPD Header format 20 is shown comprising a 
fib source port number field 19 and a destination port number 
in field 21. In order to identify the length of data there is 
w p a field 22 which defines the total number of bytes in the 
w header and data field 24. A 16 bit check sum is provided 
D in field 23. 

"'*rjZ 

j.g0 Refer now to Figure 4 showing a schematic repre- 

H; sentation of a TCP Header format which resides in the data 
\1 field 18 of the IP Header. The TCP Header format 25 is 

shown having a field 19' which identifies the sender port 
number similar to that described in Figure 3. The field 
25 21' defines the destination port number of the receiver and 
is similar to the field 21 in Figure 3. The 32 bit se- 
quence number 26 identifies the first sequence number for 
the data being sent in this particular TCP Header. The re- 
maining fields of the TCP Header format shown in Figure 4 
30 are standard and are well known in this industry and do not 
require a detailed description. 
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Refer now to Figure 5 showing a block diagram of 
the preferred embodiment of the present invention system 27 
comprising a central hub or airborne platform computer 28 
connected to a conventional internet network and also con- 
nected in a broadcast configuration showing an airborne 
communications network* The central processing unit 28 is 
shown having protocol levels LI and L2 at the ethernet 
level, having level L3 at the internet protocol level and 
having a transport control protocol level L4 at the trans- 
port level as described hereinbefore with reference to Fig- 
ure 1. The information formatted at the ethernet level is 
outputted as a TCP protocol data format package on line 29 
and is inputted to a flow control system 31. In the pre- 
ferred embodiment of the present invention, the flow con- 
trol system has been implemented in Packeteer (,CM) software 
similar to QoS software packages provided by such firms as 
Cisco, Starburst, Sitara and Checkpoint Systems. The TCP 
data on line 29 also appears at the output of the flow con- 
trol system on line 32 and is input into the PC or control- 
ler 33 at the TCP input port. The PC or controller 33 is 
shown comprising a logic portion 34 and a memory portion 
35. The memory and logic of the controller 33 determines 
by examining the flag data in the TCP format header whether 
or not the data should be converted to UDP format or should 
continue its journey in its TCP format at the output port 
33P. 

The UDP or TCP data and its header is coupled to 
a transmitter/receiver 36 which is provided with an antenna 
37. The information is broadcast to a plurality of ground 
stations 39 each comprising a transmitter/receiver and an 
antenna 38. The ground stations 39 are capable of deter- 
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mining their maximum rate of data input or reception and 
may transmit this information from antenna 38 to antenna 37 
which in turn is transmitted via line 43 to the CPU 28. 
The CPU 28 uses this information to reprogram the flow con- 
trol system 31 via line 45. 

In a similar manner, the system described herein- 
before also may operate on an internet or a LAN or a WAN. 
In this event, the output information from port 33P is sup- 
plied to the interface 41 which may be an internet inter- 
face and to line 42 which may be a local area network (LAN) 
line or wide area network (WAN) line 42. The information 
on the network 42 is supplied to the plurality of stations 
39' or to individual stations as the case may be if it is a 
point-to-point network system. Similarly, the plural sta- 
tions 39' may transmit on network 42 to the interface 41 
their ability to receive information from the computer 28 
and this information is supplied via line 44 as shown. 

Having explained the preferred embodiment system 
Figure 5 and an equivalent alternative system in the same 
drawing, it will be appreciated that both systems may not 
be operated together at the same time because one is air- 
borne and the other one is basically a ground system. How- 
ever, the computer or controller 33 which performs the con- 
version of TCP input data to UDP input data is the same and 
may be explained as follows with reference to Figures 3 and 
4. In Figure 4 there is shown a field number 21' for the 
destination port number. When a predetermined number ap- 
pears in the field 21' of the TCP header the controller 
knows that the data in this header should be converted into 
a UDP header format. This predetermined number is also 
used by the controller 33 to modify the destination IP ad- 
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dress 11 of IP header format 12 into a network destination 
IP address or a subnet destination IP address which may be 
read by all ground stations or a subset of the ground sta- 
tions, respectively. The information shown in Figure 4 is 
5 transferable directly from fields 19' , and 21' directly 

into fields 19 and 21. The controller 23 has to calculate 
the other fields and insert them in the proper place in the 
UDP header format. It will be understood that the data 
field 24 in the UPD header is usually much larger than the 
10 data field 24' in the TCP header. To overcome this prob- 
lem, the length of the field is sent over first and as sub- 
sequent TCP headers arrive they are assimilated and sent 
m over to complete a UDP header. Stated differently, a plu- 
y : 3 rality of TCP headers may be employed to generate one UPD 
|J.5 header. 

M j Having explained a preferred embodiment of using 

*fE a portion of the field 21 to flag or designate a TCP header 

i , : 

r ' ;c for conversion to a UDP,, header, it will be understood and 
H appreciated that the same flag or a similar flag could have 
ifgO been inserted in the data field 24' and accomplish the same 
^ results . The fact that the field can vary from one of the 
fields 21 to one of the other unnumbered fields does not 
affect the result achieved by the controller 33. 

A typical example of the utility of the present 
25 invention is a system which employs in an airborne platform 
the computer 28 which has assimilated from numerous other 
sources surveillance radar images, moving target indicator 
(MTI) images and all types of data which accompanies this 
information in textual £0zm. As many as a thousand ground 
30 stations may be able to implement this information. How- 
ever, it would be impossible to take particular information 
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and send it by a point-to-point communication mode to each 
of the receiving stations and have sufficient bandwidth to 
disseminate the information in a reasonable length of time 
in which it could be utilized. In order to overcome this 
5 problem, the present invention not only prioritizes the in- 
formation which is assimilated in point-to-point informa- 
tion format, but converts the information which may be dis- 
seminated in a point-to-multipoint format so that many or 
virtually all of the receiving stations may receive the 
10 most important information simultaneously and from time to 
time individual stations may receive point-to-point infor- 
mation which is not needed- or should not be disseminated to 
all of the ground stations, 
%3 Another example which is yet to be implemented is 

=T5 a food chain or department store or retail store that has a 
large number of outlets and desires to change the prices on 
B p a number of individual items throughout all of the outlets. 
\& Thus, the outlets will be treated as the ground stations 
P and the central hub is the central headquarters CPU which 
f£p disseminates the information to the retail outlets. The 
|^ present system will allow the headquarters store to simul- 
taneously change the price in the computers of the ground 
stations or outlets by equating a new price to the bar code 
scanned without changing the marked designated price on 
25 counter or display unit. 

Another example is a corporation or other entity 
that desires to send out meeting notices to all required 
attendees. The computer 28 can program the TCP data so 
that it is converted to UDP data and disseminated to the 
30 desired plural stations 39' simultaneously. 
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Since CPU 28 has updated information from its 
ground stations, it can dynamically change or prioritize 
the transmission of types of data to the individual sta- 
tions in a point-to-multipoint mode. 

Having explained a preferred embodiment in which 
the IP destination address 11 and TCP formatted data may be 
converted to network destination IP addresses and UDP for- 
matted data, respectively, it will be understood that other 
formats and fields may be employed to accomplish the same 
desired result. 



